Popular Web sites, such as large electronic commerce (e-commerce) sites, must frequently handle large numbers of clients accessing the site simultaneously. In order to serve all of the clients promptly, such a site typically uses a cluster of Web server hosts operating in parallel. Client requests to access the site via the Web, typically in the form of hypertext transfer protocol (HTTP) requests, are distributed among the hosts by a router. Routers for this purpose, such as the “eND” server produced by IBM Corporation, are known as “spray routers,” because they “spray” the incoming requests among the hosts in the cluster in order to balance the processing load among them. Each of the Web server hosts comprises a suitable computer running both a Web server process or engine, along with whatever other application engines or processes are needed to serve client requests.
Simple spray routing of client requests is possible because HTTP itself is stateless, i.e., each communication session is independent of any previous session. Therefore, after a session between a client and any one of the Web servers terminates, the next session can be set up and handled just as well by any other one of the servers. To the extent that it is desirable to remember state information from one session to the next, the Web server passes the information to be stored by a “session holder”—typically another computer in the cluster that serves as a state repository. The Web server makes the client store an identifier, generally in the form of a “cookie” on the client's disk. The next time the client submits a HTTP request to the Web site, the client identifier is read back from the client's disk. Typically, the site's Web pages are coded so that data from the stored client identifier are inserted into an appropriate field in the HTTP request headers. Alternatively, the data may be conveyed using other methods known in the art, such as in a URL rewrite mechanism, for example.
Whichever one of the Web servers receives the request from the spray router uses the client identifier to fetch the necessary state information from the session holder. Retrieving the state information is time-consuming and slows the performance of the Web server and of the cluster as a whole. Since it is not possible to predict which Web server will receive any given client request from the router, however, the servers cannot cache the appropriate state data and must retrieve it from the session holder every time there is a new HTTP request.
In some large Web sites, the router maintains a fixed look-up table of Internet Protocol (IP) addresses and assigns each client to a server based on the client's IP address. All clients with IP addresses in a given range are assigned to the same server. Thus, as long as a client's IP address has not changed from one HTTP session to the next, the client's HTTP requests will be assigned repeatedly to the same server. This approach does not address the problem of multiple application engines running on the same server. Furthermore, when one of the Web servers goes down, clients assigned to that server will receive no service at all.